Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

Claude finished @samgutentag's task in 2m 0s —— View job

Claude PR Review

• Read the changed file and PR diff
• Check for typos, grammar, and formatting issues
• Compare with related docs for style consistency
• Post review feedback

Summary

The new Stacked pull requests section is well-scoped, scannable, and matches the page's existing voice and em-dash style. Cross-references (using-the-queue/stacked-pull-requests.md#merge-the-stack-as-one-unit and ../setup-and-administration/trunk-sudo-app.md) resolve correctly. Three issues worth addressing before merge:

1. Terminology inconsistency on line 51 (blocking) — the bullet calls the UI element a "Speculative PR chip," but the same sentence says it's "labeled Stacked PR #N," and the companion doc using-the-queue/stacked-pull-requests.md uses stacked PR throughout for this combined PR. Calling it both "speculative" and "stacked" in one sentence will confuse readers. See inline comment with a suggestion block.
2. Tense on line 51 — "the combined test PR Trunk created" → "Trunk creates" (describes general behavior, not a past event). Bundled into the same suggestion above.
3. Hint placement (lines 60–62) (non-blocking style) — the Trunk Sudo / /trunk stack prerequisite is currently at the bottom of the section. The page's existing convention (lines 8–10) puts prerequisite hints up top so readers don't miss them. Consider moving the {% hint %} directly under the heading.
4. Minor wording on line 55 (non-blocking) — "Any PR page in the stack triggers the same operation" reads awkwardly; suggested a tighter phrasing inline.

What looks good

• Heading capitalization (### Stacked pull requests) matches the page's sentence-case style.
• Em-dash usage matches the existing line 70 style (spaced em-dash).
• Bold UI labels (**Add to Merge Queue**, **Cancel**) match the conventions used in the Submit a pull request to the queue and Track testing progress sections.
• The deep link to #merge-the-stack-as-one-unit is correct.

Setting review_passed = false on the strength of issue 1 — the in-sentence terminology contradiction is a real reader-confusion problem that should be resolved before publishing.
• Branch

Claude finished @samgutentag's task in 1m 8s —— View job

Claude PR Review

• Read the current state of the changed file
• Diff against origin/main to see latest changes
• Verify whether prior review feedback was addressed
• Check for new typos, grammar, formatting issues
• Post review feedback

Summary

The latest push (56e75db) is a merge of main into the branch — no content changes were made to merge-queue/chrome-extension.md since my earlier review. All three issues I flagged previously still apply, and the inline comments on lines 56, 60, and 67 remain unresolved.

Outstanding issues

1. Terminology inconsistency on line 56 (blocking) — the bullet still calls the UI element a "Speculative PR chip" while the same sentence labels it "Stacked PR #N" and tells the reader to click to "open the speculative PR." The companion page using-the-queue/stacked-pull-requests.md consistently uses stacked PR for this combined PR (verified — "speculative" appears there only in the unrelated predictive-testing context on line 142). Using both names in one sentence will confuse readers. See the inline suggestion block on line 56.
2. Tense on line 56 — "the combined test PR Trunk created" → "Trunk creates" (general behavior, not a past event). Bundled into the same suggestion.
3. Hint placement (lines 65–67) (non-blocking style) — the Trunk Sudo / /trunk stack prerequisite is still at the bottom of the section. The page convention (lines 8–10) puts prerequisite hints up top so readers don't get partway through before discovering they can't use the feature. Consider moving the {% hint %} directly under the ### Stacked pull requests heading.
4. Wording on line 60 (non-blocking) — "Any PR page in the stack triggers the same operation" is slightly ambiguous (the page doesn't trigger anything; the click does). A tightened version is suggested in the inline comment.

What looks good

• Heading capitalization (### Stacked pull requests) matches the page's sentence-case style.
• Em-dash usage matches the existing convention.
• Bold UI labels (**Add to Merge Queue**, **Cancel**) are consistent with neighboring sections.
• Cross-references to using-the-queue/stacked-pull-requests.md#merge-the-stack-as-one-unit and ../setup-and-administration/trunk-sudo-app.md resolve correctly.

Setting review_passed = false — issue 1 is the same in-sentence terminology contradiction flagged before, and it's still a real reader-confusion problem that should be resolved before publishing. Issues 3 and 4 are style suggestions and not blockers on their own.

Fix issue 1 →
• Branch

Verification status (2026-05-06): live

Verified: customers can use this. Ready to publish.

• Eng PR: trunk-io/trunk2#3825 (merged 2026-05-05)
• Flag: none
• Signals:
  • Merge commit on main (status: behind, merge intact)
  • No feature flag in eng PR body or diff (browser extension ships changes unflagged)

Branch state: up to date with main.

Suggested next action: merge.

Claude finished @samgutentag's task in 1m 29s —— View job

Claude PR Review

• Read the current state of the changed file
• Diff against origin/main to see latest changes
• Verify whether prior review feedback was addressed
• Check for new typos, grammar, formatting issues
• Post review feedback

Summary

The latest push (8e9b08a — "correct stacked-PR section against extension source") resolves every issue flagged in the prior reviews and goes further by reconciling the button labels against the actual extension source. This PR is ready to merge.

Prior issues — all resolved

1. Terminology consistency ✓ — line 60 now reads **Stacked PR chip** — a link to the combined test PR Trunk creates for the stack (labeled **Stacked PR #N**). Click it to open the stacked PR on GitHub …. "Speculative" is gone; "stacked PR" is used consistently and matches the companion page using-the-queue/stacked-pull-requests.md.
2. Tense fix ✓ — "Trunk creates" replaces "Trunk created" (general behavior, not a past event).
3. Hint placement ✓ — the Trunk Sudo / /trunk stack prerequisite (lines 51–53) is now directly under the ### Stacked pull requests heading, matching the page convention at lines 8–10.
4. Wording on Add-to-queue bullet ✓ — line 64 now reads **Add stack to queue** — enqueues the entire stack as one unit. Clicking it on any member PR page submits the same stack., matching the previously suggested phrasing.

Additional observations on this push

• Button labels were corrected against the extension source — Add to Merge Queue → Add stack to queue, and Cancel → Remove. These differ from the labels in the Submit a pull request to the queue / Remove a pull request from the queue sections above, but per the commit message that's because the extension genuinely shows different labels in the stacked-PR view. Trusting the author's verification against the source.
• Vale vocab addition — enqueues added to .trunk/configs/vale/styles/config/vocabularies/terms/accept.txt to silence a false-positive typo flag from the new bullet. Consistent with the existing enqueueing and (?i)enqueued entries on adjacent lines.
• Style consistency ✓ — sentence-case heading, spaced em-dashes, bold UI labels, and the using-the-queue/stacked-pull-requests.md#merge-the-stack-as-one-unit deep link all match neighboring sections.
• Re-enqueue note (line 67) — slightly redundant with line 64 since both say "click on any member PR page," but it explicitly calls out the post-remove use case, so it earns its keep. Non-blocking.

What looks good

• The section now reads as a coherent, fact-checked addition that mirrors the rest of the page's voice.
• Cross-references resolve correctly.
• No typos, grammar issues, or broken markdown.

Setting review_passed = true — all previously blocking issues are resolved and no new issues were introduced.
• Branch

Claude finished @samgutentag's task in 1m 13s —— View job

Claude PR Review

• Read the current state of the changed files
• Diff against origin/main to see latest changes
• Verify whether prior review feedback was addressed
• Check for new typos, grammar, formatting issues
• Post review feedback

Summary

This PR was merged as commit fb6254a on 2026-05-07. The merged content matches the state approved in the prior review (8e9b08a) — every previously-flagged issue is resolved in the final version on main.

Verified on the merged file (merge-queue/chrome-extension.md)

1. Terminology consistency ✓ — line 60 uses Stacked PR chip consistently with the companion page using-the-queue/stacked-pull-requests.md. "Speculative" is no longer used to describe this chip.
2. Tense ✓ — "the combined test PR Trunk creates" (general behavior, not past event).
3. Hint placement ✓ — the Trunk Sudo / /trunk stack prerequisite (lines 51–53) sits directly under the ### Stacked pull requests heading, matching the page's existing convention at lines 8–10.
4. Bullet wording ✓ — line 64 reads **Add stack to queue** — enqueues the entire stack as one unit. Clicking it on any member PR page submits the same stack.
5. Button labels ✓ — Add stack to queue / Remove (per the extension's actual stacked-PR view, not the single-PR view's Add to Merge Queue / Cancel).
6. Vale vocab ✓ — enqueues was added to .trunk/configs/vale/styles/config/vocabularies/terms/accept.txt alongside the existing enqueueing / (?i)enqueued entries.
7. Cross-references ✓ — both using-the-queue/stacked-pull-requests.md#merge-the-stack-as-one-unit and ../setup-and-administration/trunk-sudo-app.md resolve.
8. Style ✓ — sentence-case heading, spaced em-dashes, bold UI labels — all match neighboring sections.

No typos, grammar issues, or broken markdown in the merged content.

Setting review_passed = true. The PR is already merged; this is a confirmation that the merged state is clean.
• Branch